Contingency and Continuity Planning Policy

last updated: 16 December 2020

Identified Potential Risks

The following identified risks will trigger a potential contingency event, each event is independently risk assessed and will be managed in accordance with this policy.

Natural disaster

• Fire
• Flood
• Sudden cessation of trade
• Sale of company
• Hardware failure
• Software failure
• Malicious attack
• Data breach
• Litigation
• Data theft

Application continuity and security

Our hosting network has multiple redundancies and security procedures including, but not limited to;

• 24 x 7 x 365 Manned Security & Monitoring
• Smart Card access policies
• Internal and External CCTV systems
• Security breach alarms
• 24 x 7 environmental monitoring systems
• Constant evaluation and testing of all systems
• N+1 redundant Heating Ventilation Air Conditioning (HVAC) system
• Fully redundant air handling units provide constant fresh airflow
• Raychem Fluid Detection
• FM200 fire suppression equipment
• Dual independent power feeds, backed up by dual battery string Uninterrupted Power Supplies (UPS) systems (deployed as standard)
• 2 Megawatt diesel generators to protect services from any single power failure
• Diverse fibre routing via multiple carriers
• Truncated internal cable network
• ODF/DDF (Optical Distribution Frame/Digital Distribution Frame) bandwidth
• Cross Connection to a number of Tier 1 carriers
• Internal inventory systems track all cables, circuits and cross-connects
• Scalable architecture including multiple redundant core switches and routers

Contingency Plan

Once triggered a contingency action plan will be implemented;

• provide an action plan with SMART objectives (Specific, Measurable, Agreed, Realistic and Timescaled).
• ensure that the action plan deals effectively not only with the immediate and underlying causes but also the root causes.
• include lessons that may be applied to prevent other adverse events, eg assessments of skill and training in competencies may be needed for other areas of the organisation.
• provide feedback to all parties involved to ensure the findings and recommendations are correct, address the issues and are realistic.
• should trigger and be fed back into a review of risk assessment.
• communicate the results of the investigation and the action plan to everyone who needs to know.
• include arrangements to ensure the action plan is implemented and progress monitored.

Bug and error reporting may not trigger the contingency plan unless exceptionally severe. Bug fix procedure and error reporting (minor to mission critical) flow is illustrated below.

The maximum duration of service interruption upon total failure will be 24-48 hours. In this time a new server will be provisioned using the most recent whole server backup, brought online, checked and the most recent database backup accessible applied.

We expect service level to be near to 100% once the total failure procedure is complete, with a 24 hour allowance for complete back-up roll back.

We expect completely normal service to be resumed within a further 24 hours after the total failure procedure has been completed.

Triggering the Contingency Plan

Predictable Events

In the case of predictable and knowable events, such as the sale of the company, the contingency plan will be enforced at a set date that will be adequately advertised and discussed with our clients.

Unpredictable Events

When the event is unpredictable the plan will be triggered immediately once the issue is identified.

Failover testing, Pen testing and frequency

Our applications are penetration tested after every major release point. Any issues are identified and rectified and the penetration tests repeated.

Backup and recovery strategies are tested monthly for effectiveness, reliability and integrity.

Timely access to components necessary to make use of data

In the event of the company no longer trading we will make available an open source version of the code as it stands at the last version update.  A detailed technical specification of the requirements will accompany this to run the code. All user data will be available to download.

Minimize risk of loss - Data and Backup

Database transaction logs are backed up every 15 minutes and full database backups are taken once a day, encrypted by AES256. An offsite backup is created once a week. Virtual host guest OSes (including the web and database servers) are backed up daily using Veem, encrypted using AES256, and moved to offsite storage. All backups are kept for 30 days.

In the event of data loss due to error or mis-configuration the database can be rolled back to the suitable transactional data point and the data repaired. In the event of total failure or server crash a new instance can be brought online with a absolute maximum data loss of 24 hours.

Application code and content (uploads and other user data) is backed up in full each day to off-site storage. Centralised versioning software is used to maintain a full and complete backup of the application code and all changes.

Updates and changes are developed on the beta branch of the application code and fully tested before being merged into the release branch.

Data Encryption and protection against data theft 

Physical servers are protected by secure access and are only accessible by authorised personnel.

Strong password policies are enforced on all physical servers.

All default ports are closed and only essential public ports are opened. Database traffic is restricted to only authorised servers and are not publicly exposed.

Latest OS security patches are applied on release.

All database stored passwords are encrypted with individual SALTs.

We recommend all clients utilise SSL to encrypt user to server traffic and prevent man in the middle attacks.

All API access is encrypted via SSL.

Changes

If you require further support or a different service level agreement, please contact the team on info@teamkientic.co.uk.  

This agreement can be updated on a customer basis with 2 weeks notice and the agreement of both parties.

Customers can opt out of any single update, but any opt out may have unforeseen impacts and TeamKinetic cannot be held responsible or liable for these.  Any opt out is at the risk of the customer.